|
In computer programming, design smells are "structures in the design that indicate violation of fundamental design principles and negatively impact design quality".〔Girish Suryanarayana, Ganesh SG, Tushar Sharma (2014). "Refactoring for software design smells: Managing technical debt". Morgan Kaufmann. ISBN 978-0128013977〕 The origin of the term "design smell" can be traced to the term "code smell" which was featured in the book ''Refactoring: Improving the Design of Existing Code'' by Martin Fowler.〔Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2.〕 Different authors have defined the word "smell" in different ways: * N. Moha ''et al.'': "Code and design smells are poor solutions to recurring implementation and design problems."〔N. Moha, Y. Gueheneuc, L. Duchien, and A. Le Meur. "Decor: A method for the specification and detection of code and design smells". IEEE Trans. Softw. Eng., 36(1):20–36, January 2010.〕 * R. C. Martin: "Design smells are the odors of rotting software."〔R. C. Martin. ''Agile Software Development, Principles, Patterns, and Practices''. Addison-Wesley, 2003.〕 * Fowler: "Smells are certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring."〔 Design smells indicate the accumulated design debt (one of the prominent dimensions of technical debt). Bugs or unimplemented features are not accounted as design smells. Design smells arise from the poor design decisions that make the design fragile and difficult to maintain. It is a good practice to identify design smells in a software system and apply appropriate refactoring to eliminate it to avoid accumulation of technical debt. The context (characterized by various factors such as the problem at hand, design eco-system, and platform) plays an important role to decide whether a certain structure or decision should be considered as a design smell. Many a times, it is appopriate to live with design smells due to constraints imposed by the context. == Common design smells == * Missing abstraction〔 when clumps of data or encoded strings are used instead of creating an abstraction. Also known as "primitive obsession" 〔 and "data clumps".〔 * Multifaceted abstraction〔 when an abstraction has multiple responsibilities assigned to it. Also known as "conceptualization abuse".〔Trifu A. "Automated strategy based restructuring of object oriented code". In Proceedings of the 7th German workshop on software-reengineering (WSR); 2005.〕 * Duplicate abstraction〔 when two or more abstractions have identical names or implementation or both. Also known as "alternative classes with different interfaces"〔 and "duplicate design artifacts".〔Stal M. "Software architecture refactoring". Tutorial in The international conference on object oriented programming, systems, languages and applications (OOPSLA); 2007.〕 * Deficient encapsulation〔 when the declared accessibility of one or more members of an abstraction is more permissive than actually required. Also known as "hideable public attributes/methods".〔Sonargraph-quality: A tool for assessing and monitoring technical quality. Available at: https://www.hello2morrow.com/products/sonargraph/quality.〕 * Unexploited encapsulation〔 when client code uses explicit type checks (using chained if-else or switch statements that check for the type of the object) instead of exploiting the variation in types already encapsulated within a hierarchy. Also known as "simulated polymorphism".〔Structural Investigation of Software Systems (SISSy) Tool. Available at: http://sissy.fzi.de/SISSy/CMS/index.html.〕 * Broken modularization〔 when data and/or methods that ideally should have been localized into a single abstraction are separated and spread across multiple abstractions. Also known as "data class"〔 and "data records".〔Structural Analysis for Java Tool (Stan4J). Available at: http://stan4j.com/.〕 * Insufficient modularization〔 when an abstraction exists that has not been completely decomposed, and a further decomposition could reduce its size, implementation complexity, or both. Also known as "God class",〔 "fat interface",〔 and "blob class".〔InFusion - Design flaw detection tool. Available at: http://www.intooitus.com/products/infusion.〕 * Cyclically-dependent modularization〔 when two or more abstractions depend on each other directly or indirectly (creating a tight coupling between the abstractions). Also known as "dependency cycles"〔SDMetrics - A UML design quality metrics tool; 2012. Available at: http://www.sdmetrics.com.〕 and "cyclic dependencies".〔Page-Jones M. "The practical guide to structured systems design". 2nd ed. Prentice Hall; 1988.〕 * Unfactored hierarchy〔 when there is unnecessary duplication among types in a hierarchy. Also known as "significant sibling duplication"〔 and "orphan sibling method/attribute".〔 * Broken hierarchy〔 when a supertype and its subtype conceptually do not share an “IS-A” relationship resulting in broken substitutability. Also known as "inappropriate use of inheritance"〔Budd T. "An introduction to object-oriented programming". 3rd ed. Addison Wesley; 2001.〕 and "misapplying IS A".〔Page-Jones M. "Fundamentals of object-oriented design in UML". Addison-Wesley Professional; 1999.〕 * Cyclic hierarchy 〔 when a supertype in a hierarchy depends on any of its subtypes. Also known as "knows of derived"〔 and "inheritance/reference cycles".〔Sefika M, Sane A, Campbell RH. "Monitoring compliance of a software system with its high-level design models". In Proceedings of the 18th international conference on software engineering, ICSE ‘96, Washington, DC, USA; 1996. p. 387–96.〕 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Design smell」の詳細全文を読む スポンサード リンク
|